1. Introduction

This project is an illustration of how Model-Driven Engineering tools and techniques can help in other model-based fields such as scientific activities (Agronomy in our case study).

1.1. People involved in this case study

1.2. Conventions

Here are some typographical conventions :

  • we denote modelsc a model in the sense of the scientific community

  • we denote modelmde a model in the sense of the [MDE] community

2. Expectations

  • In terms of modeling capabilities:

    • this is phase 1 of modeling (close to what GVLE does right now)

    • we want to write text and use graphical rendering to communicate

  • In terms of interoperability with other models:

    • DEVS is already a standard?

  • In terms of semantic/execution/simulation:

  • In terms of normative/standard support …​

  • xxx to be completed by Hélène Raynal xxx

3. Description of the context

In this section we provide some element to understand the kind of modelssc that scientific entities such as INRA manipulate daily.

3.1. Available material

Here’s the list of inputs we had:

3.2. Screen captures

Note

More can be found (in French) here.
Modeleconceptuelintegre
Figure 1. Les composants principaux

Pour la partie description hiérarchique, on utilise une approche systémique basée sur la connaissance du domaine (exemple on met ensemble les processus qui relèvent du bilan hydrique de la plante) et le niveau d’interaction. La profondeur de décomposition est fonction des attentes du modélisateur et des habitudes. On s’appuie aussi sur les propriétés DEVS (formalisme sous jacent).

Exemple de modèles dans l’interface gvle (VLE est le logiciel utilisé dans RECORD) :

gibgjbgc
Figure 2. Modèle dans l’interface GVLE, 1er niveau
ejdecgib
Figure 3. Modèle dans l’interface GVLE, 2ème niveau: Boîte 2CV (qui correspond au modèle de culture)
fagbhhdf
Figure 4. Modèle dans l’interface GVLE, 3ème niveau: Modèle SOilFull (processus du sol)

4. Contributions

This section describe the modeling experiments.

THe basic documents (in addition to the one presented before) is the following : documents/ModèleExploitationAgricole.pdf

4.1. Approaches

There are several ways to tackle the problem.

We can follow [IDM12] metamodeling process:

idm12
Figure 5. A metamodeling environment construction process

We can also follow [MDSEP12]:

  1. Modeling domain analysis

  2. Modeling language design

  3. Modeling language validation

Parler du papier de [Selic07] pour l’approche profil du CEA LIST. CF. cette figure.

4.2. DSL

4.3. Profile-based approach

Contribution by sd, Florian Noyrit, JMB.

4.3.1. What is a profile ?

  • Abstract syntax for a new language

    • Set of stereotypes

    • Set of OCL constraints

profile JT

4.3.2. General process

The idea behing this approach is that there will be some benefits in the use of the UML™ standard. Hence the DSL will be based on UML™ by using the profile mechanisms.

profil BS
Figure 6. A profil based approach (taken from [Tatibouet14] and inspired by [Selic07])

As illustrated in this figure, here is the processus we can follow:

Step #1

Starting from the expected DSL (most of the time a modelsc or a graphical représentation) and a description of the domain model (modelmde)

input
Figure 7. Inputs: description of the domain model
Step #2

A domain modelmde is more precisely defined (e.g. a class diagram such as Main concepts of the domain model)

step1
Figure 8. From modelsc to modelmde
image001
Figure 9. Main concepts of the domain model
image002
Figure 10. Concepts of the domain model linked to activities
Step #3

The concepts (e.g., Farm in Main concepts of the domain model) are mapped to the more suitable UML™ elements (e.g., Class in Mapping concepts with UML metamodel to define a profile)

step2
Figure 11. Mapping domain concepts to UML metamodel
image003
Figure 12. Mapping concepts with UML metamodel to define a profile
Step #4

If the concepts directly match UML™ concepts (or if there is a way to slightly modify them so that they match) then it is possible to define a profile. (see e.g., Mapping concepts with UML metamodel to define a profile)

Step #5

Else another solution (e.g., defining a metamodel from scratch) should be studied.

Step #6

It is time then to "customize" the DSML to make it as close as possible as the user domain representation.

dsml
Figure 13. Customizin the DSML
image004
Figure 14. Improving the profile
Note

There are different ways of defining the domain model:

  • the domain expert provides the domain model (e.g., UML™ class diagram)

  • the UML™ expert translate the concepts from the stakeholders into a domain model

  • the UML™ expert and the domain expert build a modelmde as close as possible of the expected DSL and the UML™ expert extract the core concepts in a domain model

4.3.3. Iterative process

The above process is iterative. The constructs are introduced by step. The profile is experimented in a modelsc importing the profile so that the user can validate that the concepts are captured adequatly. This is were the UML™ expert can use tuning possibilities.

4.3.4. Improvements

The next steps can consist in:

  • defining a dedicated diagram

  • providing a wizard for the new language

  • defining a specific property view (File ▸ New …​ Property View Configuration and then right click on the generated property)

  • Working on the concrete syntax:

    • customizing the styles (look & feel)

    • customizing New ▸ Child

    • customizing the Model explorer

    • packaging together the profile, the property view, the palette, etc.

Tip

  • Papyrus provides a DSML Configuration plugin to help on these steps.

  • There is also the possibility of defining a Feature that group together a set of profiles

    wizard

4.3.5. Example of work on the concrete syntax

Let us illustrate the need for a specific concrete syntax.

Structural Domain Model
FarmingDomainModelStucture
Functional Domain Model
FarmingDomainModelFunctional
Structural profile
FarmingProfileStructure
Functional profile
FarmingProfileFunctional
Using the profile: Farm structure
FarmStructure
Using the profile: Papyrus context
ModelingInterface
Crop Workshops description
CropWS
Activity description (UML Activity Diagram)
CornActivity
Activity description (UML Activity Diagram)
WheatActivity
Customizing the Model Explorer
ModelingInterfaceZoomModelExplorer
Customizing the Palette (structure)
ModelingInterfaceZoomPalette1
Customizing the Palette (activities)
ModelingInterfaceZoomPalette2
Customizing the Palette (property view, structural element)
ModelingInterfaceZoomPropertiesView1
Customizing the Palette (property view activity element)
ModelingInterfaceZoomPropertiesView3
Animation and external tools coupling
moka1
moka2
moka3

4.4. Conclusion

4.4.1. Profile definition

  • in terms of stereotypes (extending metaclasses)

  • adding specific properties to the stereotype (e.g., period in this figure)

  • adding OCL constraints

4.4.2. Main differences

  • Using ecore

    • the process consists in starting from scratch, from an empty metamodel

    • the domain model is then define by construction

  • In the UML profile approach

    • we start with an existing (complete) metamodel

    • and the profiling activity consist in restricting it to specific elements

    • the assumption is that their is a benefit in having both additional concepts and tooling, notably in terms of

      • extensibility mecanisms

      • scalability

4.4.3. (honest) Feedbacks

  • Easy tuning and customizing possibilities

  • Almost like doing regular UML modeling

  • UML good knowledge required

  • Not trivial

  • Great work from CEA (3.5 days of work)

  • Need close loop with the client (agile manifesto)

4.4.4. DSML from scratch: the "Wysiwyg approach"

word
Figure 15. Free and easy to edit from scratch

  • No constraint on what we type

  • Immediate visualization of the result

  • Possibility to have templates

  • More and mode styles and quality

4.4.5. DSML as UML profiles: the "LaTeX approach"

dsl
Figure 16. Formal and constrained typing

  • Constrained language

  • No immediate visualisation of the result

  • Naturally based on templates

  • Rich in libraries and styles

  • Possibilities to see what you get on (almost) real-time

  • Collaborative and user-friendliness improvements

4.4.6. Converging

  • DSML vs Profile-based ⇒ wrong approach

  • DSML or Profile-based ⇒ good question

  • Both Sirius and Papyrus part of Polarsys!

polarsys logo

Frequently Asked Questions

What are the needs in terms of simulations/executions ?

(by Pascal Dayre): we need to explore complex agro-system dynamic. More information with Helene’s presentation http://devlog.cnrs.fr/idm2013 (vidéo, slides)

Why DEVS? And is it the only target language?

(by Pascal Dayre) DEVS n’est pas un langage cible mais un formalisme mathématique qui permet de modéliser les systèmes selon le paradigme événementiel discret. C’est le formalisme englobant qui permet de formaliser les intéractions entre les sous-composants d’un modèle et ceci de manière hiérarchique (sous-modèle de sous-modèle, etc…​). DEVS est implémenté par le langage VLE. Les spous-comosants d’un modèle est lui implémenté avec d’autres approches formalisées ou mathémathique pour des systèmes qui ont un comportement "continu", équations au différence (c’est la démo lors de la visio), d’autres composants pourraient a priori avoir un comportement décrit par un réseau baysien, etc. Par contre, si on se trouve dans un cas discontinu, on retombe dans le formalisme DEVS pour redécouper en sous-comosant continu avec la déclaration des événements entre sous-composants (modèle atomique au sens DEVS). Donc, le langage VLE implémente ce formalisme DEVS en gérant un bus inter-composants. Il offre des passerelles vers d’autres logiciels R, etc…​ et permet de programmer ses propres comportements en langage C++.

Il offre donc un framework: je ne trouve pas dans la doc de description général de ce framework, ni la grammaire du langage. Peut-etre qu’Helene a une info, un contact. Par contre:

Le Langage cible est le langage VLE:

DEVS abbreviating Discrete Event System Specification is a modular and hierarchical formalism for modeling and analyzing general systems that can be discrete event systems which might be described by state transition tables, and continuous state systems which might be described by differential equations, and hybrid continuous state and discrete event systems. DEVS is a timed event system.

DEVS is a high level formalism that has the ability to encapsulate other formalisms. VLE allows you to use several formalisms in DEVS framework:

  • Ordinary Differential Equations: QSS based on quantization and DESS a wrapping of classical numerical schema like Runge-Kunta, by example.

  • Cellular automaton : CellDevs.

  • Difference equation: DifferenceEquation.

  • Petrinet : PetriNet.

  • Discrete and finite state automaton: Moore and Mealy machines, FDDevs and statechart : FSA.

  • Decision making: an extension of execution of activities plan based on conditional, temporal and precedents constraints.

Glossary

MDE

Model Driven Engineering (IDMfr)

References and links

About…​

Document réalisé par Jean-Michel Bruel, Benoît Combemale (bruel@irit.fr,benoit.combemale@irisa.fr) via Asciidoctor (version 1.5.1) de 'Dan Allen', lui même basé sur AsciiDoc. Pour l’instant ce document est libre d’utilisation et géré par la 'Licence Creative Commons'. Licence Creative Commons licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.

Photo credits: